home *** CD-ROM | disk | FTP | other *** search
/ PC World Komputer 2010 April / PCWorld0410.iso / hity wydania / Ubuntu 9.10 PL / karmelkowy-koliberek-9.10-netbook-remix-PL.iso / casper / filesystem.squashfs / usr / share / doc / aptitude / README.hier < prev    next >
Text File  |  2008-11-19  |  3KB  |  81 lines
  1.                        Configurable package hierarchies
  2.  
  3.   This document describes a mechanism for allowing aptitude and other APT
  4. frontends to dynamically generate a package hierarchy using information
  5. stored on the system.  The mechanism allows packages to be placed in arbitrary
  6. groups and groups to be placed within arbitrary other groups.
  7.  
  8. ===============================================================================
  9.  
  10.                              Abstract structure
  11.  
  12.   The hierarchy information is input as a directed acyclic graph.  Each node
  13. of the graph is either a "group" or a "package"; only "group" nodes may have
  14. successors.  The user may define one or more groups as the starting point(s)
  15. for the displayed hierarchy; the program will then generate a tree from the
  16. graph using those nodes as the top-level nodes in the tree.
  17.  
  18.   This is not a terribly complex system with tons of research behind it;
  19. however, it IS very simple (trivial, in fact) to implement, and will easily
  20. beat the pants off the horrendous Section-based grouping that we are stuck
  21. with today.
  22.  
  23. ===============================================================================
  24.  
  25.                                  File format
  26.  
  27.   Hierarchy information is stored in a tagfile format similar to that
  28. used by dpkg.  (this is done primarily because apt has simple facilities for
  29. parsing such files)  Each record in the tagfile after the first will have one
  30. of two formats:
  31.  
  32.   (a) Package records
  33.  
  34. Package: foo
  35. Parents: group1,group2,...,groupN
  36.  
  37.   (b) Group records
  38.  
  39. Group: bar
  40. Description: A holding pen for foos.
  41. Parents: group1,group2,...,groupN
  42.  
  43.   In each case, the first line identifies the package or group for which
  44. information is being entered, while successive lines provide information
  45. about the package or group.  It is an error if both a Group and a Package
  46. tag exist in a given record.
  47.  
  48.   References are resolved after all data has been read (ie, references
  49. to not-yet-defined groups will work)  Dangling references are allowed;
  50. if an item is placed into a group which does not exist at all, that
  51. reference will simply be ignored.  Circular references will generate
  52. an error.
  53.  
  54.   Package names must be valid package names for the Debian package
  55. database.  If a name which specifies a package not in the current APT
  56. cache is encountered, it will be ignored.
  57.   Group names must follow the same rules as package names, with the
  58. exception that they may contain any number of periods separating
  59. groups of alphanumerics/hyphens.  (so "dnb.lisp" is a valid group)
  60.  
  61.   Note: groups and packages have entirely disjoint namespaces.  It is
  62. valid (albiet confusing) for a group "linux-doc" and a package
  63. "linux-doc" to coexist.
  64.  
  65.   In the future, the Description field may have an extended component,
  66. interpreted in the same way as the extended Package description.  It
  67. may also become possible to override package descriptions from within
  68. a hierarchy definition.
  69.  
  70.   One exception to this format exists.  The first record in a file may have
  71. the format:
  72.  
  73. Global: yes
  74. Realm: britannia
  75.  
  76.   In this case, all future group names in the file which do not
  77. include a "." will have "britannia." prepended to their name.  This is
  78. a mechanism to avoid namespace collisions.
  79.  
  80.   Future global file options may be added.
  81.